-
Notifications
You must be signed in to change notification settings - Fork 4.1k
refactor: new app wiring DRAFT #25388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
This reverts commit 47e1ec1.
simapp/app_di.go
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is your stance on the future of runtime if this is deleted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right know I see depinject module config and runtime still exist, and only the example on how to wire that app is deleted. Would you consider runtime legacy or deprecated then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just a draft to explore some new ways to wire up an application. We have been hacking on a few approaches so nothing here is final.
TBD on whether we remove runtime, but in the future I would like us to have only one way to wire your application.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I am not commenting on the rest indeed, due the the big DRAFT in the PR title :D
but this direction looks very much like the deprecation of runtime (and prob depinject then).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally as the original author of depinject and runtime, I feel that it's unfortunate that we didn't either 1) fully migrate to depinject or 2) find a solution that was simpler and satisfactory for everyone. Dependency injection wouldn't have been my first choice for how to solve this because it introduces a level of non-linear magic, but given the complexity of initialization dependencies it was seen as the least bad approach. There were quite a number of working group calls that explored different options and ended up with the depinject approach. I don't know the full context of this new approach, but whatever it is, I suggest we carefully the consider prior work, why it is the way it is and its pros/cons.
No description provided.